Min Stack
Push: O(1).
Pop: O(1).
Peek: O(1).
GetMin: O(1).
Auxiliary space: O(n).
An alternative stores only values that establish new minimums, reducing typical auxiliary storage.
We need a stack that can return the current minimum in O(1). How would you implement push, pop, top, and getMin?
If you push the values 5, 2, 8, 1 onto your min stack, what does getMin return after each operation?
Our product uses a min stack to track the lowest price in a sliding window of user actions. If we now need a 'removeBottom' operation that removes the element at the bottom of the stack, how does that affect your design?
During a recent bug, getMin started returning the wrong value after a series of pops. Walk me through how you'd debug the issue.
What trade‑offs would you consider between using a separate auxiliary stack versus storing (value, currentMin) pairs in the main stack?
We are building a high‑throughput trading engine where each thread maintains its own min stack for price ticks. How would you ensure thread safety and minimal contention while preserving O(1) getMin?
If the stack must be persisted to disk for crash recovery, how would you modify the min‑stack design to allow efficient recovery of the current minimum?
Our legacy system uses a linked‑list based stack with O(N) min retrieval. We want to migrate to a min stack across multiple microservices that share state via a distributed cache. What architectural considerations and migration steps would you propose?
When scaling the min‑stack service to handle billions of operations per day, what monitoring, sharding, or alternative data‑structure strategies would you evaluate to keep latency low and guarantee correctness?